Package by Feature
PBF
Package by Feature
とあるディレクトリ構造
どういうものか?
機能ごとにディレクトリを分ける
例えば、Layered Architectureを採用している際でも、Layerで区切るのではなく、機能ごとに区切る
https://gyazo.com/cce5e47cdccd054932843be7f3a987ef
同じ色を同じディレクトリに入れる感じ
背景
Packagingの要求としてコードの認知しやすさを高めたいmrsekut.icon
その手段として、Colocationがある
概念的に近いものが物理的に近い場所にあるとわかりやすい
人間が認知できる範囲には限界がある
予めスコープが切られていれば、その中を探すだけで済む
認知しやすければ、その分ノイズが減るので、他の問題(e.g. 依存関係)についても考えやすくなる
では、何によってColocationするか?
一般に「同じ機能に関するものは、同じタイミングで修正されることが多い」という性質がある
であれば、機能ごとに括るのが自然ではないか?
機能単位でColocationした構成がPackage by Featureである
同じ機能に関するものが、近くのファイルに存在している
関連する概念が、同じディレクトリの中に見つかる
機能を削除する際は、ディレクトリごと削除すれば済む
file treeを見ればfeatureが一覧されるため、どういうプログラムなのか把握しやすい
表面的な嬉しさの例
Package by Feature
ディレクトリを見れば、機能の一覧を把握できる
機能を削除する場合、ディレクトリを削除するだけ
機能を追加しやすい
機能まるごとの移動もしやすい
後に階層がネストしたとしても、directoryを丸ごと移動させるだけで済む
code:before
Login
Post
code:after
Auth
Login // ネストが深まったが、ディレクトリを移動するだけで済む
Register
Post
package間の結合度が下がる
異なるpackageとの依存が薄くなる
別々で並行で開発できる
追加で考えるべき観点
1つのFeatureとはなにか
依存の方向性
PBLとPBFにおける依存関係
またがるものの扱い
PBFにおいて、複数のfeatureに跨るものはどう扱うか?
関連
Package by Component
Folder by Feature
参考
Package by Feature
/mrsekut-book-4048930656/282 (第34章 書き残したこと)
PBFではなく、Package by Componentの解説が書いている
/miyamonz/Package by Feature